<!-- 
Copyright 2005-2009, Foundations of Success, Bethesda, Maryland 
(on behalf of the Conservation Measures Partnership, "CMP") and 
Beneficent Technology, Inc. ("Benetech"), Palo Alto, California. 

This file is part of Miradi

Miradi is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License version 3, 
as published by the Free Software Foundation.

Miradi is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with Miradi.  If not, see <http://www.gnu.org/licenses/>.
-->  

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<STYLE type=text/css></STYLE>
</HEAD>
<BODY>
<table><tr>
<td>
<IMG src='images/Umbrella/agile.png' border=0  width=48 height=37 hspace=10 ></IMG>
</td>
<td>
<H2>Agile Software Development</H2>
</td>
</tr></table>
<br>
<HR>
<H3>A.&nbsp; The User's Perspective</H3>
<P>When the members of the Conservation Measures Partnership first started 
discussing this program, not knowing much about software development, we bought 
a copy of the <i>Dummies Guide to Software Project Management</i>.&nbsp;This guide 
basically said that we had to work through the following steps:</P>
<P>1. Gather all requirements<br></br>
&nbsp;&nbsp;2. Design the entire system<br></br>
&nbsp;&nbsp;&nbsp;&nbsp;3. Write the code for the application<br></br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4. Test and debug the entire&nbsp;application<br></br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5. Deploy the application which will now work<br></br>
</P>
<P dir=ltr>Even at the time, this "waterfall" method of programming - so named 
because once you&nbsp;complete one step, there is no going back to it 
-&nbsp;seemed like a difficult thing to do.&nbsp;We weren't sure exactly what we 
wanted the program to do, so it seemed hard to design the entire 
system.</P>
<table>
<tr>
<td>
<P>When we met with the Benetech team, they told us about a relatively 
new programming method called <STRONG>Agile Development</STRONG>, typified by a 
specific process know as <STRONG>Extreme Programming 
(XP)</STRONG>.<STRONG>&nbsp;</STRONG>As outlined in the following diagram, Agile 
Development involves going through an iterative process of defining user stories 
(things that people want the software to do), writing modules of code in weekly 
iterations, testing these iterations, and then using the results to refine both 
the code and your list of stories.</P>
<P>Light bulbs started going off&nbsp;-&nbsp;here 
in the world of software was&nbsp;the same adaptive management approach that we 
have been advocating in conservation!!&nbsp;And interestingly, it has evolved 
for the same reason - a need to make decisions in the face of complexity and 
uncertainty.&nbsp;There is no way two years ago that we could have predicted 
that we would need many of the features that are in the current release of the 
software - we could only arrive at them through a systematic, iterative 
process.</P>
</td>
<td width='410'>
<img src='images/Umbrella/agileProgrammingCycle.png' width='406' height='307'></img>
</td>
</tr>
</table>
<P dir=ltr>Just as adaptive management is not a license to do "whatever you 
want," but instead must carefully state your assumptions and then 
deliberately&nbsp;test them, so too Agile Programming requires a disciplined 
approach.&nbsp;We the users can suggest any stories we want.&nbsp;But the 
engineers will then log them into our tracking system and provide estimates of 
how much programming time will be required to complete each step.&nbsp;We then 
meet with the engineers before each weekly iteration to collectively&nbsp;decide 
what stories we will do that week, trying to get the most "user value" for that 
week's worth of engineering time.&nbsp;We users also then have to make sure that 
we test and provide feedback on the results of that weeks' iteration.</P>
<P>We're 
not sure that this agile process would work with a much larger project requiring 
dozens of programmers versus the handful that we worked with.&nbsp;And it is 
obviously clearly dependent on having software engineers who&nbsp;are deeply 
skilled, enthusiastically willing to keep changing things, able to dive in and 
rapidly get up to speed on new subject material, ask intelligent questions, be 
problem solvers, and make substantial contributions to design and function 
elements that enrich submitted stories as well as produce new 
stories.&nbsp;But&nbsp;with those caveats, the agile process&nbsp;seems to work 
really well.&nbsp; </P>
<P dir=ltr>So why are we providing you with all this navel gazing about our 
development process?&nbsp;There are two important messages we wish to 
convey.</P>
<P dir=ltr>1.&nbsp; <STRONG>We&nbsp;Need Your Stories</STRONG>&nbsp;- Because we 
are using Agile Programming, we collectively have the power to change whatever 
we want in this software program.&nbsp;If you the user find something minor that 
bothers you (when you click on a factor, the wrong thing is selected) or have a 
grand idea of how to improve the software (adding an entire&nbsp;module that 
does....), you should know that we can make it happen.&nbsp;Drop us a note at <A 
href="mailto:feedback@miradi.org">feedback@miradi.org</A>.&nbsp;We won't 
guarantee that we will satisfy all requests.&nbsp;But we will certainly consider 
it - and at least get back to you to discuss it with you.</P>
<P dir=ltr><STRONG>2.&nbsp; Agile Programming / Adaptive Management 
Works</STRONG> - Although we are preaching the gospel of&nbsp;Adaptive 
Management in conservation, we (as of yet) still only have a limited number of 
stories showing that this approach adds value.&nbsp;Our experiences with Agile 
Programming have left us convinced that in the face of uncertainty and 
complexity, a flexible and yet deliberate iterative approach is the only way to 
go.&nbsp;We can't imagine undertaking another software program any other way - 
and it give us faith that we are on the right track in conservation too.<BR></P>
<p></p>
<HR>
<H3 dir=ltr>B.&nbsp; The Engineer's Perspective</H3>
<p>
Agile software development has been around for decades, but was only recognized 
and named a few years ago. 
In 2001, practitioners of so-called "lightweight" methodologies got together and created the 
<a href='http://www.agilemanifesto.org/'>Agile Manifesto</a>. 
Since then, Agile development has continued to gain popularity and credibility, 
especially for projects with fewer than ten developers.
</p>
<p>
Shifting to 
<a href='http://en.wikipedia.org/wiki/Agile_programming'>Agile Programming</a> 
from a more traditional methodology can be very challenging. 
Users take on more responsibility for prioritizing, 
and are expected to remain actively involved throughout the entire development cycle.
Programmers have to let go of the idea that everything can be planned up front, 
and be willing to change direction as required. 
In order for that to be possible, the source code must always be kept clean and simple, 
and most agile projects use extensive automated tests to ensure high quality.
</p>

<p>
Extreme Programming (XP) is one specific form of Agile development. 
It is so famous that some people think that all Agile development must be "extreme". 
XP can work well, but it is very difficult to implement successfully, 
and is not appropriate for all teams or projects.
For Miradi, we used a subset of XP that is also a variant of the
<a href='http://en.wikipedia.org/wiki/Crystal_Clear_%28software_development%29'>Crystal Clear</a> 
methodology.
</p>

<p>
For us, the benefits of Agile Programming include:
<ul>
<li>Early delivery of working software</li>
<li>Responsiveness to changing requirements</li>
<li>Low defect counts</li>
<li>Efficient use of funds</li>
<li>Avoiding end-of-cycle "death marches"</li>
<li>Continuous learning and improvement</li>
<li>More fun!</li>
</ul>
</BODY></HTML>
